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(57) ABSTRACT 

The Shared~Intemet~Storage-Resource_provides Jmemet -j 
b ased file storage; retrieval- access, control, and manipu la- 
ti on for a use rrAdditionally, an easy-to-use user interlace is 
provided both for a browser or stahdralone application. The 
entire method provides means by which~users canestablish, 
u^7and:maintai£T61es on th"e~ Internet in a manner remote 
from theirlocal computers yet in^malmer that is similar to 
thc-file: manipulation Aised on" their ' local computers. A high? 
capacity or: other storage system is attached to the Internet 
via' an optional internal network lhat~alsp_scrves to gencrate 
and direct metadataTregarding the stored files. A web server 
using a CGI, Java®-based, or other interface transmits and 
retrieves TCP/IP packets or other Internet information 
through a load balancer/firewall by using XML to wrap the 
data packets. File instructions may be transmitted over the 
Internet to the Shared Resource System. The user's account 
may be password protected so that only the user may access 
his or her files. On the user's side, a stand-alone client 
application or JavaScript object interpreted through a 
browser provide two means by which the XML or other 
markup language data stream may be received and put to use 
by the user. Interne t-to-Internet file transfers may be effected 
by directly downloading to the user's account space. 

1 Claim, 15 Drawing Sheets 
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SHARED INTERNET STORAGE RESOURCE, 
USER INTERFACE SYSTEM, AND METHOD 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 

This application is related U.S. ProvisionaJ Patent Appli- 
cation No. 60/163,626 filed Nov. 4, 1999 which application 
is incorporated herein by this reference thereto. 

BACKGROUND OF THE INVENTION 
1. Field of the Invention 

This invention relates to resources on computer networks, 
f particularly the Internet, and more particularly tOfjCfile 



nology: Server Component Model for the Java™ Platform" 
by Anne Thomas, revised December 1998, prepared for Sun 
Microsystems, Inc. and published/made available by the 
Patricia Seybold Group of Boston, Mass. 
5 Due to the nature of new technologies, terms such as 
"bean" or "instantiated" may seem unfamiliar to those new 
to the pertinent art. Reasons for this include the difficulty of 
communicating quickly new and complex subjects as well as 
the good-humored nature of those who intensely pursue the 
1° establishment of new technology, particularly software sys- 
tems. Consequently, for Java®-related systems, a coffee 
theme is often present that indicates to those knowledgeable 
in the art the general subject matter of interest. While 
distinctions may be subtle in the art, they can be very 



storag e -and-retrieval s ystem that^iavailable-worldwide.via 15 important and serve the ends of those attempting to 



me-tnternetw hict"ad ^riorially:allows'a"cUreaiUaiisferof> 
Intemet-filesjto*an"I ntemet stora^e^retnevfl ir^g^!^"""' 
I re ^ ourc %* T The-present-invention _ acts~in the-manner-of^a 5 
"to teroel-hard-disk" ~or-"Intcmct7hard"drivc"tto2providc 
f or^e:storage:and:ietrievalTeMuroesTor:useis. 
2. Description of the Related Art 
The Internet is the worldwide computer network making 
available a vast number of computer and information 
resources to institutions and individuals. A significant part of 
the Internet is the worldwide web that allows for web pages 
to be written in^HTML-and transmitted upon demand 
throughout the Internet. Recent developments have better 
established the use ofrXMLr(Exlensible Markup Language) 
as a subset of SGML (Standard Generalized Markup 



20 



25 



establish, share, and forward the technology. 

Generally, home pages or other web pages are requested 
by the user through designation of the URL (Uniform 
Resource Locator). With the transmission to the user via 
TCP/IP protocol, the information present at the URL (and 
generally a file located somewhere on a computer) is trans- 
mitted to the user. The file may have links, or pointers, to 
other resources including images, graphics, audio or video 
streams, or other resources. Mark-up language is used on the 
Internet in an attempt to provide an open-ended structure by 
which information of any sort that can be stored electroni- 
cally (or perhaps even otherwise) can be made available to 
an end user on demand. As such, the Internet is seen as a 
powerful tool making almost any information resource 



Language, ISO standard 8879:1986). FTP (File Transfer 30 available to any computer or to any person using a computer. 



Protocol) provides means by which files may be transferred 
over the Internet. All of these protocols are generally well 
known in the art, and collateral resources can easily be 
obtained to describe these further. 

Additionally, portable programming systems such as 
Java®, JavaBeans, and JavaScript have been extensively 
developed with an anticipation of future portability across 
the vast net work that is the Interoet.-Java<E^re lattd;systeins 
aUowIfoTobject-oriented programmmg-wh^b"y^o6jects3br 
"beans!!: aJ Jow'me'pa^in^of^lf^ontaine'd'robdules^with 
assorialed.processing methods- that are used to act upon the . 
a crompanyimr.da ta. Consequently, the "Dean" can travel 
through a network and, under appropriate circumstances, 
have certain processes activated allowing manipulation of 
the information contained in the bean. 

Advancements in Java®-related systems have given rise 
to the Enterprise JavaBean™ (EJB). The Enterprise Java- 
Bean™ allows for clustering of servers such that the bean is 
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Over the past several years, the personal computer has 
increased in power and capacity as commercial demand has 
driven the research and development of producers and 
vendors. It is now not uncommon to be able to easily find an 
Intel -manufactured 500 megahertz Pcnlium®-based system 
having well over 10 gigabytes of hard disk space, as well as 
32-256 megabytes of RAM. As such, the power by which 
files may be received and acted upon by the local user 
through his or her PC has kept pace with the advances in 
technology. | 

However, merercwrenUvrremain-obslacle^td-um 
acccss:to:an:individual!s:own:mformaU6^^ 
her^compuler. First of all, computers are very heavy. They 
are bulky. They generally weigh several kilograms and are 
not easily transportable. Lightweight laptop computers or 
the like generally do not have the same resources available 
to the user as a regular PC. Additionally, access to local area 
networks (LANs) is generally not available once the corn- 



given independence from specific servers on the system, yet 50 puter leaves the premises occupied by the LAN. 



can be activated or "instantiated" such that error recovery is 
easier, the system as a whole is more robust, and processing 
of the bean can be performed asynchronously so that all 
events do not have to happen at a pre-set time or serially/one 
after the other. 

Enterprise JavaBeans TM /EJBs allow serialization of 
beans. Such serialization allows the bean to be represented 
as a data stream of determined length. In essence, this is just 
a data file that is interpreted in the proper context, much the 



55 



Additionally, Internet access is often restricted by the use of 
a modem. Modems generally provide data transmission 
speeds on the order of 56 kilobits per second. This is 
approximately the same as 7 kilobytes per second. However, 
headers and other information are required to properly 
transmit information over the Internet and increase the 
effective size of files. 

Even with the increased availability of broad band access 
to the Internet, it becomes an important feature of electronic 



same as any electronic information file. Such serialization of 60 information processing and the like in order to provide 

the EJB allows it to be replicated and stored in case of rcsidcnt"rcsources-on-th"e^Intcraet. Such resources could 

catastrophic failure of a preferred server or the like. include the sharing of files and the like in a manner that are 

If the server upon which the instantiated EJB dies, goes easy to use and understand, 

down, or fails, a previously replicated twin can be used to Due to these and other restrictions regarding data 

continue the process and allow for error recovery. More 65 transport, transmission, and reception, a need has arisen for 

information about Enterprise JavaBeans™ technology can means-by-wbichrfilesrandiotherzdataimayjberavailable 

be found in the white paper, "Enterprise Javabeans™ Tech- worid^ide^thraughrthe-lriterneirarulinotlticdztO-a-local 
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^coropute^The-present-ihveaiibD-addiesses'-thistde m 
-providing means bywhich filesandother data-may be stored, 
'orT-ihe^ Interaet^d made- available - worldwide :ihrough;ihe, 
Internets 

SUMMARY OF THE INVENTION 

The present invention provides an "Intemethard driye^or 
"Internet hard disk" to and from- which - files- may be stored 
and rctficvadT'Dcnominalcd commercially as "X: Drive," the 
present invention allows users to store files of foreseeably 
any type on a resource available throughout the Internet. 
Once available to the Internet, the files stored on the user's 
X:Drivc arc available to the same extent as the Internet, 
namely worldwide. 

Note should be made that the term "X: Drive" refers both 
to the system as a whole and to the individual space 
allocated to an individual user. Consequently, reference is 
sometimes made herein to the X:Drivc system or to X:Drive 
to refer to the system as a whole. At other times, the term 
X: Drive indicates the user's individual X:Drive, or allocated 
space. The different uses are indicated by context. 

In order to effect the Shared Internet Storage Resource of 
the present invention, a central or distributed storage facility 
is provided. First and foremost is thelhigbrspeedlaccess 
storage -facility- where -files-are actuallyrstored. Such indi- 
^ Dividual storage areas may be allocated in individual limited 
'^o allotments, or be left open-ended and limited only by the 
capacity of the physical devices responsible for storage. 
Metadata, that is data about the files stored on the network 
hard drives or other storage devices, is generated and stored 
in a separate database. TherdatabaseTofrmetadataZ(lhe 
ir^dajabasc);and;toc;nctwoikTa^ 

berlmkedrbyran- internal: network. ItlislpossiHeCf6T^ttie > 
j+r- . ^ d ata^ase;to:rxfstbrod'on the same network storagerfaararoi 

A^A^^y^* - * device: o n: wMch;TisCT;rnes:are^ 
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l 



-ff(* ^ I nternet 



ment:may;select.whetheror-not ^distribute or.consolidato 
me^Ubasc^with:the:^etwoTk:storage , . 
AlsoaUached:to:me:mteraal.network : i^^bserver that 
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s erves -t oj: gc ne raLeTandltransmiUthlTTin for ma lioaT tor the 
I nterriet rand:ultmiately;the:user. The web server files may 
pass through a load balancer and/or firewall before proceed- 
ing on to the Internet. The same is similarly true for 
information coming into the web server from the Internet 

XML may be used in combination with JavaScript or the 45 
like to provide two means by which the Shared Internet 
Storage Resource of the present invention may be achieved. 
The first is a JavaScript object which may be transmitted to 
a browser program running on the user's computer. Such 
browsers may include ones that are well known, including so 
Netscape® Communicator and Microsoft® Internet 
Explorer. Alternatively, a stand-alone application may be 
installed and stored upon the user's computer. This stand- 
alone application serves to intermediate the user commands 
with the web server and ultimately the metadatabase in the 55 
Internet storage device. 

As an additional enhancement, the user interface may be 
a client program that meshes seamlessly with standard user 
presentations in WYSIWYG (what you see is what you get) 
graphic user interfaces (GUIs). As such, a drive may be 60 
shown oo the user's computer and may be denominated "x:" 
(or "y:" or "z:", etc., depending upon user preferences ). The 
user:can: men-read-rxo m-.oriwritcito:me-x:\~Share3 : rnte 
S toragc;Rcsource:drivc;much:in: the same .way.'as -yon:would' 
the -local - a: \ and c: \h aid dri ve > $5 

WhcB-me'-uscTsKute^wnhisor her comp 
u'on:mat:is : stored r 6n^ra^Sh^ 



qf-ibe - present - inve n tio n . re m ai as - on . the - 1 n le roe I—The : user 
can;then:access: such~ hifbrmaribn:firam:anolher: computer,- 
ajU)mer;gwgrapbic"locatirjnror-even:giveipenrn^i6^io 
share-fiJesionitheiShared -Interne ^Storage Resource with "D 
others.: Password protection or other security protocols: may' 1 
bejuscd :to:limit:or~discriminate"access: to the user's tiles. 

The Shared Internet Storage Resource of the present 
invention allows for direct Intemet-to-Internet file transfer to 
a user's allocated X: Drive file space in a process referred to 
as "Skip the Download" or "Save to My Xdrive." 

OBJECTS OF THE INVENTION 

It is an object of the present invention to provide a:Shared 
InternetrStoragerResojurce-on which users may store and 
retrieve files to make them available to themselves, or 
possibly others, throughout the Internet. 

It is an additional object of the present invention to ^tufj, 
provide~all^manner'of~fik~access~aDd"control"Renerally> •f"-^— /) 
available:t6Tfile^l6ca-t6~the.users forsuch~Ihternet-stdred* ^ Q>0TOtA0\ 
filesr> 

It is an additional object of the present invention to 
provide an easy-to-use and readily understood user interface 
through which files may be stored, retrieved, and manipu- 
lated on the Internet. 

It is an additional object of the present invention to gather 
metadata regarding such files and to store such metadata in 
a database. 

It is yet another object of the present invention to provide 
a plurality of means by which *mtemetrStored:files*may-be' 
manipulated ~and"controlled> 

It is yet another object of the present invention to provide 
a" browser-based: access:to:IntemetrStored:files? 

It is yet another object of the present invention to provide 
stand-alone application access to Internet-stored files. 

It : is yet : a^ther-object"6f-the present invention to provide 
means ; by ; which:Internet:files:may:be:stored:on:an:Interneb 
resource: byr a: directrlnternetTlOrlntemet- lransfer:SubjecMOj 
the^control: of :a:remo te: or 7 l imited^resource :user. 

These and other objects and advantages of the present 
invention will be apparent from a review of the following 
specification and accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic view of the X:Drive system of the 
present invention. The different tier levels are shown, along 
with the marking indicia of a circle, triangle, square, and 
star/asterisk corresponding to the same indicia in FIG. 3. 

FIG. 2 is a schematic view of Java® library objects 
operating in the transactions or data exchanges occurring in 
the present invention. 

FIG. 3 is a detailed flow diagram showing the operation 
of the present invention. Indicia including a circle, a triangle, 
a square, and a star/asterisk correspond to tier levels shown 
in FIG. 1 and indicate the level of operation of the steps 
shown in the flowchart of FIG. 3. 

FIG. 4 is a flowchart showing the operation of the XDFile 
Enterprise JavaBean™ (EJB) used in the present invention. 

FIG. 5 is an overview of the Java® architecture used to 
effect transactions in the present invention. 

FIG. 6 is an alternative schematic diagram of the Java® 
architecture shown in FIG. 5. 

FIG. 7 is a schematic and flowchart diagram showing the 
IO (input/output) for the database transactions of the present 
invention. 
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FIG. 8 is a schematic diagram of the data recovery process 
as effected by the FilelO component of the XDFfle object 
used in the present invention. 

FIG. 9 is a schematic depiction of failure recovery ele- 
ments. 

FIG. 10 is a schematic and flowchart diagram showing 
virus protection effected in the present invention. 

FIG. 11 is a schematic and flowchart diagram of the 
Internet-to-rcsource transfer ("Skip the DownloadVSave lo 
My Xdrive") as set forth in the present invention. 

FIG. 12 is a schematic and flowchart diagram of the client 
system used in the present invention. 

FIG. 13 is a Windows™ desktop display showing both the 
client and web-browser applications. 

FIG. 14 is a display of a web browser pointing to a user's 
X: Drive. 

BRIEF DESCRIPTION OF THE APPENDICES 

Appendix 1 is a listing of web site/server code use to 
achieve the present invention. 

Appendix 2 is a listing of the code used on the client side 
to achieve the present invention in a Microsoft® Windows™ 
environment. 

Appendix 3 is a listing of the JavaScript code used to 
achieve the present invention in a Sun Microsystems® 
Java® environment (including one on a browser), 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT^) 

The detailed description set forth below in connection 
with the appended drawings is intended as a description of 
presently-preferred embodiments of the invention and is not 
intended to represent the only forms in which the present 
invention may be constructed and/or utilized. The descrip- 
tion sets forth the functions and the sequence of steps for 
constructing and operating the invention in connection with 
the illustrated embodiments. However, it is to be understood 
that the same or equivalent functions and sequences may be 
accomplished by, different embodiments that arc also 
intended to be encompassed within the spirit and scope of 
the invention. 

Appendices 1, 2, and 3 provide the source code for, 
respectively, the Web Site/Server Code of the X: Drive 
Shared Internet Storage Resource system of the present 
invention; the Windows Client Code; and the JavaScript 
Listings for the present invention. These Appendices are 
incorporated herein by this reference thereto as if set out in 
their entirety. It is contemplated that these Appendices 
provide a full, complete, and enabling disclosure to those of 
ordinary skill in the art or less by which the present 
invention may be achieved. 

Additionally, the reference numbers used in conjunction 
with the figures are numbered such that the 100's place of 
the number indicates the number of the drawing figure. For 
example, the 600 series of reference numbers refers to FIG. 
6, while the 200 series refers to elements shown in FIG. 2. 
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for execution for programs available and processed either 
locally and/or over the Internet. In light of the foregoing, it 
can be seen that the present invention may act as a bridge or 
may pave the way towards a more inter-networked commu- 
nity for the use and processing of electronic information. 

The virtual disk drive provided by the present invention 
may be selectively shared with others or kept entirely 
private. Additionally, and as set forth in more detail below, 
the use of a mc Lad at abase provides quicker access and the 
ability to distribute the information regarding the legion of 
XrDrivc accounts over a wide geographic area, enabling 
redundant preservation of user information by server clus- 
ters implementing Enterprise JavaBeans® (EJBs), or other- 
wise. 

The Shared Internet Storage Resource, User Interface 
System, and Method set forth herein is generally referred to 
as "X:Drive " Context reveals whether or not the term 
X:Drive is referring either to the system as a whole or the 
individual's own account. 

The X:Drive system of the present invention uses network 
application practices and may rely upon Java® Enterprise 
JavaBeans™ (EJBs) to enable distributed and clustered 
computing and file management envir onm ent. A longlwith' 
such~Java® ; blislfd 'wfd^twoiS^entedxlesignr thT-X-Dri ve^ 
system of-me;pTesem:mvenUon:also1c6ntempTa lOfcfo- 

(Web:ba^d:Distni™te7rAutfco7^ The use 

of such technology is foreseen as providing wide support by 
the user community as well as speed and development, 
refinement, and polishing. 

As shown in FIG. 1, the X: Drive system 100 has a 
multi-tiered, network-based application infrastructure. The 
multi-tiered nature of the system allows it to separate 
operations in an efficient manner. The network -based aspects 
of the X:Drivc system allows it to disperse resources geo- 
graphically as well as allow a high degree of communication 
between different aspects or facets of the system. 

The XrDrive system may be considered enabling tech- 
nology as a medium that is independent of the applications 
and uses to which it is applied. The X: Drive system is 
currently based on object-oriented principles with each 
application layer responsible for a discreet functionality or 
aspect of operation. Both hardware and software resources 
may then successfully experience heavy re-use with both 
scalability and flexibility inherently provided. While these 
advantageous aspects of the X: Drive system are achieved, as 
a multi-tiered system, X:Drive involves a higher cost of 
complexity and planning. Thus, those who would seek to 
wrongly copy the X: Drive system would do so without 
accruing the great expense in time and money necessary to 
achieve the present X:Drive system. They would ride on the 
backs of those who not only developed the system, but also 
those who got it to work right and in a commercially-reliable 
manner. 

The use of tiers in the X: Drive system of the present 
invention is realized in both the network systems and the 
application systems involved in achieving X: Drive. 
As shown in FIG. 1, a variety of tiers, or layers, are 



Thc^present"mvrnu"o^rovidcsracmethod:byiwhich:an) 60 present between the client 102 and the ultimate data 



Internet hard d^prjbard_drive:may:be:achieved in a manner 
similM:to;a:biird:diskior;hari 

inoUvidual:on;me;lc>cal"CTmputer.-Additionally, as Internet 
use becomes a more familiar and everyday event for people, 
the resources provided by the present invention may allow 
the actual use of the Internet hard drive or X:Drive set forth 
herein to act as such a resource with the files being called up 
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resources 104. Between the client 102 and the data resources 
104, are one or more layers or tiers, accomplishing the 
following. 

The client 102 may be coupled to a public network 106 
(such as the Internet) that may include a DNS redirector 108 
as well as a load balancer 110. The public network 106 may 
then lead into' a web server network 120. The web server 
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may then lead into an application network 122, which in turn 
leads into an EJB (Enterprise JavaBeans™) network 124. 
The EJB network 124 may lead into a transaction network 
126, which in turn leads into the data resources 104. 

The client 102 may be either a web- or browser-based 
application or an application resident on a Windows™ X 
system (the X indicating the version of Windows applicable, 
i.e., Windows® 95, Windows® 98, Windows® 2000, etc.). 
Requests generally originate from the client as the X:Drive 
system 100 is one that operates at the command of users 
directing the client program. Client requ ests m ay be made 
versus the Hypertext Transfer Protocol (HTTP) GET/POST 
function. In a preferred embodiment, the GET/POST opera- 
tion may be augmented with Web-DAV extensions to the 
HTTP protocol. Commands are transmitted by the client 102 
are sent to the DNS redirector 108, which then isolate the 
request via a proxy server process. A proxy server process 
prevents a direct connection between the client 102 and the 
other downstream resources in the X: Drive system 100. 
Such proxy serving prevents inadvertent or mischievous 
disruption of service by allowing only certain commands or 
information to be propagated through the X: Drive system 
100. This prevents mischievous users from disrupting the 
system as such rogue commands are intercepted by the 
proxy server and denied further propagation. 

After the client command has passed through the DNS 
redirector/proxy server 108, the request by the client 102 is 
then directed to the most appropriate facility. As the X:Drive 
system is scalable, facilities may be distributed 
geographically, even over the face of the globe. This allows, 
at the outset, more efficiencies to take place in the X:Drive 
system 100 of the present invention so that more users may 
be served more quickly and so that the advantageous fea- 
tures of the X:Drive system may be realized by the widest 
number of users in the quickest way possible. 

Due to the construction and architecture of the X:Drive 
system 100, a number of machines/servers running a number 
of different processes may be distributed over a wide area. 
Broad band or high-speed access as provided by Internet 
backbone or the like may allow the X:Drive system to be 
effectively carried out over the entire face of the planet. The 
scalability and flexibility of the present invention augments 
its utility. Such advantages are further advanced by efficient 
use of the resources so that greater and better service can be 
provided. 

Upon receiving the request from the client 102, the DNS 
redirector 108 transmits the requests on to a load balancer 
which may provide a second proxy process under HTTP 
protocol and transmit the request to the least-loaded and 
most-available web server on an internal, non-routable, or 
other server network 120. 

The web server network 120 may be non-routable and 
may comprise a number of individual machines or servers 
processing the HTTP or other requests from one or more 
load balancers 110. Each of the web servers 140 in the 
network 120 may handle HTTP requests for static content, 
such as HTML and graphic files. The web servers may proxy 
all requests for dynamic content to a Java® application 
network 122. 

As used in the X: Drive system 100 of the present 
invention, the Java® application networks may be non- 
routable. The use of non-routable facilities in the X: Drive 
system 100 of the present invention indicates their operation 
in a local area network (LAN). However, between tiers, the 
individual networks themselves may be available such that 
a web server 140 in Illinois may pass requests for dynamic 
content to Java® application clusters 122 in Wisconsin. 
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Each Java® application cluster 122 may be composed of 
a number of Java® application servers 142 with each server 
142 handling display functions necessary for user accounts, 
including the generation of XML, HTML, and other 

S instructing displays for either browser or application clients 
102. If a Java® application cluster 122 receives a resource 
request from the web server tier 120, the Java® application 
cluster 122 will pass the resource request onto the Enterprise 
JavaBean™ EJB network tier 124. 

10 As for the web server 120 and Java® application networks 
122, the EJB network 124 may also be non-routable and 
operate upon a LAN. The EJB network may be an EJB 
cluster having a number of EJB servers 144. Each EJB 
cluster handles the business logic and resource access meth- 

15 ods and protocols required for the resource requests and 
management. The EJB cluster (EJBC) caches memory of 
common resources such as the pooling of data connections 
and the like, as well as data objects. Resource access 
requests and uansmissions are then passed out to the trans- 
action network tier 126, which may also be non-routable. 
The transaction network tier 126 has a transaction processor 
146 which controls, operates, and guarantees access and 
transactions on different resources. These different resources 
arc the ullimate data resources 104 that may include NFS 

^ (Network File Server) disk arrays 150 and databases 152. 
The NFS disk arrays 150 may supply the actual storage 
capacity for the files of generally any size. The databases 
152 comprise records of information regarding each of the 
files (metadata) stored by the NFS disk arrays 150 under the 

30 X:Drive system 100. 

By bifurcating the file information in databases 152 
separate from the actual files themselves on the NFS disk 
arrays 150, file information and user queries can be handled 
much more quickly as display components of the present 

35 invention arc importanl to provide the user information 
regarding the status and availability of the files stored on the 
X:Drive system 100. Consequently, although a user may 
have a hundred separate files in an X: Drive directory, he or 
she may be only interested in one. Consequently in order to 

40 provide the user the information necessary to make the 
decision as to which file to receive, move, rename, delete, or 
store, the use of the database provides a very quick and easy 
means by which such user requests can be satisfied. It is 
anticipated that the actual use of the file storage facilities on 

45 the NFS disk arrays 150 or the like may comprise only a part 
of the operations of the present invention. Having the ability 
to display, select, and determine file operations is one of the 
useful advantages provided by the X:Drive system 100 of 
the present invention. 

50 Note should be taken of the non-numerical indicia present 
in FIG. 1. Most notably, a circle is associated with the client 
102, a triangle with the Java® application cluster 122, a 
square with the EJB network 124, and a star/asterisk with the 
transaction network. These non numerical indicia corre- 

55 spond to those set forth in FIG. 3. As different actions arc 
performed at different tiers in the present invention, the 
non-numerical indicia provide an easy or visual means by 
which the operation of the different tiers can be indicated in 
FIG. 3. 

60 FIG. 2 shows a logic diagram in sequence structure for the 
Java® library objects used in the X: Drive system 100 of the 
present invention. Generally, throughout the description of 
the X:Drive system 100 of the present invention, the prefix 
XD indicates "XiDrivc." For example, in FIG. 2 the steps/ 

65 status indicators of XDError stands for X: Drive Error, and 
XDXML stands for X:Drive Extensible Markup Language. 
Likewise, the use of the term XDFile indicates X:Drive File 
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as a Java® library object effecting and intermediating the file FilelO objects ihea query the common monitoring objects to 

operations of the present invention. determine the state of the system. In the present system, the 

In FIG. 2, the Java® system 200 allows operations to be monitoring object is denominated the Mount Point Status 
performed on the metadatabase 202 and the operating sys- bean, or MPS bean, 534 (FIGS. 5 and 9). 
tem (OS) File System 204. Additionally, the XDFile object 5 Additionally, disk level transactions are carried out by the 
210 may activate or instantiate the Database. Search object FilelO object 212. Under the management of the FilelO 
216. The XDFile object 210 may be activated, or invoked, object 212, user accounts are able to span or traverse several 
by the FileAction object 220. The FileAction object 220 may disks. The spanning of such several disks enables better 
also activate the Databasc.Scarch 216 and Database. Big- recovery from failure should an error occur or system 
Search 222 objects. Operations of the Java® library objects 10 resources become unavailable in an unpredictable manner, 
in the system 200 as shown in FIG. 2 may be contingent The XDFile object 210 uses FilelO 212 to handle the file 
upon the SessionSecurity object 224, which may instantiate system transactions. By using the Database .Transaction file 
or use the Database .Search object 216 and/or the Database. object, the XDFile object 210 handles database file trans- 
Transaction object 214. The SessionSecurity object 224 may actions. The XDFile object 210 coordinates transactions for 
return a separate object 226 to the UserData object 230. The 15 both the FilelO object 212 and the Database .Transaction file 
Database object 236 may inherit or transmit from its Trans- object 214 to keep both synchronized and to handle failure 
action 214, Search 216, and/or BigSearch 222 objects. should it occur. 

The information generated may then be transmitted to the ThT-UscrDau:object^O:hola^:user;o^aiDr:a session:of \\ j^T^r 

Database 202 for meta-information and the OS File System therXiDrivesysteni; A session is basically a span of time for 

204 for the actual data. If an error is generated during the 20 which a user engages the XrDrive system. Methods are ^^flltC 

operation of the Java® library object system 200, an XDEr- included in the UserData object 230 to manipulate the user 

ror object 240 may serve to handle the error while a status, so that the activity may be monitored, as well as 

successful operation may be returned in the form of the whether or not the user has logged in. 

XDXML object 242. In the Java® library object system 200 The SessionSecurity object 224 uses web logic session 

of FIG. 2, the Database 202 may contain intelligence or 25 mechanisms to create the UserData object 230. It does this 

programming for connection to SQL databases and the like. by returning a separate object 226. The SessionSecurity 

Options regarding the operations of the database 202 may be object 224 authenticates a user's login and expires old 

read from a configuration file. The Database object 236 may sessions with re-direction of such old sessions to appropriate 

be able to connect multiple databases for redundancy in the pages. 

case of repeated or redundantly archived information, or for 30 -r^ FileAction object 220 may have cbUdren classes and 

functionality in order to connect to that database which contain logic for determining request types such as user 

responds most quickly to the requests and commands. requests, administration requests, etc. Tests for file action 

The Database object 236 determines which database requests such as quotas and permissions, etc., may also be 

operation to perform and/or to which database to send ^ handled by the FileAction object 220. The FileAction object 

operations based on the type of request it receives. For 220 accesses the file methods in the XDFile object 210. 

example, transaction requests may demand a separate data- jh c XD Error object 240 reads a configuration file of error 

base from those of regular query and BigSearch 222 ij sls wn j cn gives each error an I.D. number. Such error lists 

requests. In order to maintain more efficient operation, the preferably pivot on the language in which the X:Drive 

Database object 236 generally sends session users to the ao system 100 of the present invention is programmed. Such 

same database whenever possible so that latency and data- ]; sts should also be able to pivot on the partner with which 

base replication is not passed on to the user. me X: Drive system 100 operates. Default values for the lists 

The Database .Transaction object 214 is able to handle may be to X:Drive errors in the English language. The 

larger SQL statements such as those that would cause a load XDError object 240 preferably holds errors in a stack and 

on the database. The Database/Transaction object 214 may 4J returns any such errors from the stack. Additionally, the 

spawn children classes that handle the transaction logic in XDError object 240 preferably accepts new errors by code 

order for more efficient operation. or by message. 

The DatabascSearch object 216 is designed to handle The XDXML object 242 accepts an object and delivers as 

smaller SQL statements and has children classes for specific output an XML representation of a transaction or status 

search types, such as those along anticipated and common 50 requested by the user or client software, 

fields or types of information. FIG. 3 shows the data flow through the X:Drive system 

The Database. BigSearch object 222 handles larger, non- 100 of the present invention, particularly that as reflected by 
transactional SQL statements such as those used for reports the tiered configuration shown in FIG. 1. From a starting 
in system accounting, monitoring, or otherwise. Children point 300, a request is sent by HTTP POST/ GET co mmand 
classes of the Database.BigSearch object 222 would handle S5 at step 302. Web?D AVIprotocoL :may^aTs^ bc~used Undl is 
specific large searches such as those that might be imple- cturen tiy:cqrisidered:prefeTable^ The send request is imple- 
mented on a monthly or other periodic basis. mentcd on the client 102 and is evaluated by the web server 

The FilelO object 212 inherits and overrides Java®'s data 120 as a request for static content in step 304. If the request 

file object. The file object contains logic to engage multiple is for static content, the file is served by the web server 120 

disks or resources for redundancy and/or functionality and 60 at step 306, and the file is displayed at step 308 by the client 

contains the functionalities necessary to manipulate files on 102. 

the OS File System 204. The FilelO object 212 may react to If at step 304 the request for static content is evaluated as 

the JMS (Java Messaging Service) events triggered by negative, a proxy request is issued by the web server 

events on the disks of the OS Hie System 204. network 120 to the Java® application cluster 122 at step 312, 

Alternatively, one or more monitoring objects may be 65 The request is received by the Java® application cluster 

used to gather pertinent status information regarding the OS (JAC) 122 and submitted to a servlet at step 314. The Java® 

File System 204. When monitoring objects are used, the application cluster (JAC) 122 then parses the request header 
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at step 316. The Enterprise JavaBean™ (EJB) network 124 the "database -152 for fast r etrieva l— sorting,- se a rcfa'ing/ 

then authenticates the request at step 318. If authentication lintringrand other capabilities beyond standard file systems, 

cannot be achieved, process control is then re-directed to the Thejtctual -file-data-is'stored by theOtprive-systcnj'lOO-in 

re-login page via the JAC network 122 at step 320. If ne^work-attached-slorage-units-ar-storage-arca networks> 

authentication succeeds at step 318, the JAC network 122 s s^ : as : tb>»-showD-m-HG.J;.Uic:NIS-disk:ajraysa50. 

then parses the multi-part form data at step 324. To access files that exist in this hybrid environment 

The JAC network 122 then determines the type of request <*^f Y d ^ 

at step 326. The request is then submitted to the FileAction 4 Sn« fhe 

-J* _ „_ , . . , . data in two-pbase committal transactions, b I U. 4 shows the 

EJB 220 at step 325. The EJB network 124 then evaluates deuils of ^ 

the request at step 330 in order to ensure that all the business 10 In nG ^ ^ m &{ 

rules and other applicable UmUations axe met, such as quota one Qf ^ fiy£ dukC ned triaa ^ If me ^lion is to be a 

UmUations, pemissions, and the like If 4be evaluation is t ^ fa made at the ^ mt m lf ^ action 

successful at step 330, the EJB network 124 then submits the ^ a mc read( enUy fc madc at mc fik read point m Jf thc 

request to the XDFile EJB 210 at step 332 and on to the action ^ a file wrilej entry fa made at ^ file point 406. 

transaction processor 146. The appropriate actions are then " ]f ^ action ^ a fife cnlfy ^ mad{ . at mc dclctc point 

taken via the transactional database 152 and the disk arrays 408, If the action is a file move, entry into the XDFile EJB 

150. If the business rule evaluation 330 fails, an error may 210 is at the move entry point 410. 

be generated and, as for other errors in the data flow process Beginning first with a file copy action beginning at the 

of FIG. 3, a session error object 334 may be generated in a cop y point 402, the evaluation of the operation occurs at step 

session error stack 336. 20 420, where determination is made whether or not the action 

In effecting the data transfer to the ultimate system is a read transaction, lf the action is a read transaction, 

resources 104, evaluation is made as to the operation in step program flow proceeds onto the read action and entry point 

340. If thc operation is not a data read operation such as a 404. The corresponding database action 424 is then taken, 

directory listing or file read, the error stack is checked at step As the action is a read transaction, the corresponding daU- 

342. If an error has occurred, the error status is sent to the 25 ba f Jf read * nd eval ^ Uon * mad f » . to w ^er or 

i- , im * . iaa tk. 1- . im ,u „ ,„ not the database action, m this case read action, has been 

client 102 at step 344. The client 102 then accepts the , . , , ir * , ,. . 

•„ a vwi a a ^,v^„ successful at step 428. If the read action is not successful, the 

fransmitted XML code and renders the appropriate display c are ^ ro]led ^ if a( ^2. An error is 

for the user at step 346. If the error stack evaluation step 342 at sl 436 and mc XDFfle await5 

does not reveal any error, a success message is generated at instruclions< If ^ evaluation at step 428 regarding 

step 350, and the subsequently-generated XML is received ^ database actitm was SUCC essful, action can then be taken 

by the client 102 and displayed by the user at step 346. on mc actual filc itsclf on the os Filc System 204 at step 

If at the evaluation step 340, the operation is not a data 440. In the present case, the FileOS Action 440 is a read 

read action, the error stack is checked at step 352 much in action, and the file may be read into a temporary buffer or 

the same way as it was at step 342. If an error has occurred, 35 other memory space. The FileOS Action is evaluated for 

the error status is sent to the client 102 at step 354. Thc error success at step 444. If the FileOS Action step 440 was 

status message is then received as XML code by the client unsuccessful, a fatal error is returned at step 448, and the 

102 at step 346 and displayed to the user. If at evaluation changes, if any, are rolled back at step 452. If the evaluation 

step 352 the error stack reveals no errors, the evaluation is a t step 444 was successful, evaluation is madc as to whether 

then made by the EJB cluster as to whether or not the 0 r not the action was a copy read at step 456. If the action 

operation is a file read at step 360. If the operation is a file was a copy read, return is made to the copy entry point 402 

read, the data stream is converted to a network stream and at step 464 in order to perform the write portion of the copy 

transmitted as a file to the client 102 by the Java® applica- function. If the evaluation at step 456 indicates that the 

tion network 122 at step 362. The data is then accepted by action was not a copy read action, evaluation is made at step 

the client 102 and served to the user at step 364. ^ 458 ( 0 determine if the action was a move/copy action. If thc 

Itat;eyahiation:ste7):360;me:c^eration:is:not:a:nle:read action was a move/copy action, control is then directed 

(see:FIGrj*)r.men:by:elmrinaito^ towards the move entry point 410 via step 472 in order to 
^file-metadata-sucfa-as-at dhTCtory-h^mp -indication-of-f^e, delete the original file as the success of the move/copy 

attiibutes:or:the~lflce?At step 366, the metadata retrieved transaction at evaluation step 444 indicates the success of 

from the database 152 is then translated into XML format by 50 the file write step of the FileOS Action step 440. Program 

the EJB cluster 124. The XML data is then transmitted to the control is then turned over to the move/action entry point 

JAC network 122, which encapsulates the XML from thc 410 so that the original filc may be deleted at its original 

network and sends it on to the client at step 368. The JAC location via the delete entry point 408. 

network 122 then sends thc encapsulated XML to thc client If the move/copy evaluation step 468 indicates that not 

102 for rendering and display at step 346. 55 only was the action not a copy read, it was also not a 

As indicated in the description above with regards to FIG. move/copy, then the action is committed to the system at the 

3, users utilizing the client system 102 to connect to thc ultimate system resource level 104 at step 480 and an 

X: Drive system 100 do so via the public Internet and then indication of success is then returned at step 484. 

submit requests and receive replies effecting or indicating Upon reaching the move entry point at 410, evaluation is 

the user's requests. Requests for file manipulations, such as $o made at step 490 to determine whether or not the transaction 

uploads, downloads, copies, moves and updates travel is a copy transaction. If it is a copy transaction, the program 

through each functional layer of the X: Drive system 100. then enters and executes the copy entry point 402. If not, the 

ThecSre of the:EJB'chister,"aijd'asintKcatcd in F!Gr2^the delete entry point 408 is activated to effect the remainder of 

XDFUeTEJB:^ro«aes-core-effectivene^ the move transaction. 

X:Drrv.eisysje^l00rThe:XDFne"EJB :210:is'a"raultiHiered 65 Consequently, it can be seen that a variety of actions lake 

component^ TlicrX:DriTC:systemrlO0;Stores:filejmejtodata place depending upon the state of the XDFile EJB 210 at the 

(sucfa : as : dkertoi7:stmctuTe,-fifo database action 424 and FileOS action 440 steps. 
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In performing file reads and writes, simple one-step objects intended to carry both data and processes in asso- 

actioos are taken because neither of these read or write ciation with one another, it is up to the operations of the 

actions are either copy reads 456 or move/copy 468 and so X:Drive system 100 of the present invention to selectively 

they fall into the system commit 480 and return a successful and appropriately activate the beans and enable the proper 

indication at step 484. The same is generally true for the s actions to take place. The file action container 504 is shown 

one-step delete action. Consequently, whenever a user wants in alternative representation in FIG. 6. In FIG. 6, a client 102 

to read, write or delete a file, entry can be made into the issues a user authentication request 602 and an operation 

respective entry points at 404, 406, and 408. Errors arc request 604. The user authentication request 602 is passed 

returned when necessary. into the user data stateful bean 506 in the file action 

However, the copy action 402 and the move action 410 10 container 504. The operation request 604 is passed into the 

require multiple loops through the XDFile EJB 210 in order process request stateful bean 508. The user information 

to effect their operations. For the copy function 402, the entity bean 510 then transmits information to a user infor- 

initial read must be made successfully with the evaluation mation database 610, as does the security stateless bean 512. 

step 456 then prompting the write step to occur by the return The process request stateful bean uses a first property file 

to the copy entry point at step 464. The read transaction step « 612 that is loaded upon deployment of the XDFile container 

420 is then evaluated in the negative and the write entry 520 - The property file is loaded into the admin stateful bean 

point/action 406 is invoked with the database action occur- 526 for use with the OS file system 204. A Java® transaction 

ring at step 424 to write the new information to the trans- server 620 may operate in conjunction with the database 152 

actional database 152 and, if successful, the FileOS write « well as the OS file system 204 in order to process the 

action for the data at step 440. If the file write is successful, M operation request 604. The second property file 630 may be 

the evaluation at step 456 as to whether or not the action is loaded by the recovery admin stateful bean 536 upon the 

a copy read is answered in the negative as is the evaluation bean's deployment The recovery IO stateful bean 532 and 

of the transaction as to whether or not is a copy transaction the recovery admin stateful bean 536 both transmit infor- 

executed under the move action at step 468. The resources nation to the recovery queue storage buffer 640. The mount 

are then committed, temporary resources are released, and K status bean 534 operates in conjunction with the mount 

the success indication is returned at step 484. status of the svstem 65 °- 

Consequently, for a copy transaction 402, the loop is first The recovery container 530 is called when once a failed 

made through the read function 404 and then the write resource begins to recover. Further description of the recov- 

funcuon 406. For the move action at entry point 410, a copy ery process is given below. However, FIGS. 5 and 6 operate 

transaction is first executed with the two-loop operation as 30 in tandem to show linearly (FIG. 5) and organically (FIG. 6) 

set forth previously. Upon completion of the copy action, the the structure and operation of the XDFile object 210. 

delete action 408 is implemented in order to erase the FIG. 7 shows the detail of the XDFile database compo- 

original file and its file data. Upon the third loop through the nent. A transaction processor (such as Tuxedo from BEA) 

delete step 408, the transaction is neither a read under the works in conjunction with the database transaction object 

copy command at step 456 nor a copy under the move 35 214 as well as the FilelO object 212 to provide a robust and 

command at step 468. Consequently, the move function has reliable system. Both the database transaction 214 and the 

successfully completed, the system resources are committed FilelO 212 objects include logic and/or programming to 

at step 480, and a success indicator is returned at step 484. handle situations where database or disk array access cannot 

In FIG. 5, an overview of the Java® architecture of the M be guaranteed. The database.transaction object 214 handles 

Xj Drive system 100 of the present invention is shown. The *e inherent doubt present in the system by using replicated 

Java® architecture 500 shown in FIG. 5 may generally arise or repeated clusters of databases. The replication process 

from the client 102. A file action container 504 has certain creates latency or delay, in the system. In order to accom- 

attributes and operations as do the other beans of the modate this latency, the database transaction object 214 uses 

architecture 500. Contained within the file action container ., » session object (a data construct representing a user session 

504 are a number of stateful, stateless, and entity beans, as on the X:Drivc system 100) to determine if the user's request 

weU as other containers having other beans. The file action can be transferred, or replicated, from one database cluster 

container 504 contains two stateful beans: a user date to another, in case of future system failure, 

stateful bean 506 and a process request stateful bean 508. An important aspect with respect to the reliable operation 

The user data stateful bean 506 has a user info entity bean 5Q of the X: Drive system 100 is the need to separate databases 

to 510 and a security stateless bean 512. into functional groups. While the query database may be 

The process request stateful bean 508 contains a single optimized for quick and small queries and while a transac- 

container, the XDFile container 520. The XDFile container lion database might be optimized for fewer, larger, more 

520 contains three (3) beans and a container. The three beans time consuming updates, the database layer 236 in the 

of the XDFile container 520 are: a database 10 stateful bean 55 X:Drive system 100 allows for associating SQL commands 

522, a file IO stateful bean 524, and an admin stateful bean w »th different database clusters based on functionality. 

526. The container is a recovery container 530 which Additionally, the X:Drive database layer 236 is configured 

contains a recovery IO stateful bean 532, a mount status for consolidation and addition of databases on the fly. 

stateful bean 534, a recovery admin stateful bean 536, and As shown in FIG. 7, the SQL command 710 is issued and 

a recovery process stateful bean 538. ^0 passed to a SQL command evaluator 712. A SQL evaluator 

As indicated by the nature of the beans carried by the determines the SQL type so that the SQL can be sent to the 

containers, stateful beans generally carry information about appropriate database type (that is, in the X:Drive system 

the state of the bean, process, or otherwise as useful infor- 100, the transaction database 150, the query database 152, or 

mation for the ends and operations of the X: Drive system both). 

100 of the present invention. Stateless beans generally carry 65 Upon determining the database type of the SQL statement 

no state information, and entity beans are generally for 712, the database preference is evaluated at step 714 to 

information or identification only. As Java® beans are determine if the user should be sent back to the same 
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database. If the user is not to be sent back to the same from "down" to "recovery" and the recovery object 530 is 

database, the database currently bearing the least load is called to apply all queued requests for the file action 

found in step 716, and query is then made in step 718 to container 504. This keeps the user from catastrophically 

ensure that the selected least-loaded database is still up, l° si ng uploads and other file writes, but may cause some 

running, and available. If it is, a specification regarding the 5 dc l* v i° °l c reads. 

pooling of database resources is created 720 and transmitted In the recovery system 800 of the present invention, the 

to the database object 236. Database object 236 then lakes multi-connected pooled database object, the recovcry- 

the SQLcommand and passes it to the appropriate database, enabled FilelO object 212, and the transaction processor 146 

either the transaction database 150 or the query database 152 work to £ e,her to creale a resourcc laver offenn S 

via associated connecting pools 730. 10 availability, recovery, and scalability. Additionally, this 

ir , , , . . . , * • ■ , . , resource layer (encapsulated in the XDFile EJB 210) lends 

If at stcn 718 the least loaded database is not available, an «..-.. .. L -ii j 

7 j ! l u 7 j . i^lf to replication of the data, both geographically and 

alternative database must be used and query is made at step , „ „ \_ . f , , .» i 

... . .u i. . j . u locally. Such replication preferably has the three essential 

736 to determine whether or not the ^alternate .database « ty ' * appUcaUon^Jriven, and accessible. 

If the alternate database is not up and the evahiahon step 736 ^ ^ f m ^ replication, secondary X:Drive 

^^nBlda^^^^c^ ts^^m « ctusters are enabled b ^ hicall xv** locations in 

F G. 7, a fatal error may be generated at step 738. If the - re &bffity of the X: Drive system 100. 

alternate database is up, a pool specification 720 is generated „ . . . . r ' . . 3 

, . . , v. . ■ . , ° , Consequently, data loss from one data center or even the 

and passed to the database object so that the SQL command . . ' , j, „, , , , , i 

V . , , . , . . . physical loss of an enure data center would not cause loss of 

may be implemented upon the transactional 152 databases r \ , , n . , . 

. ' r , r _, A _ n customer data or access. Re-direction would occur dynami- 

via the connection pools 730. » ^ ^ ^ informatiQn would be replicated in a pniralily 

If at step 714 the user must be sent back to the same 0 f sites across the X: Drive system 100, the query or meta- 

database, query is made at step 740 to determine if that dala databases provide multiple pointers to the user's data, 

database is still up. If it is. the request is passed to the pool , n mc KCQycrf systcm 800 QfRG ^ ^ recovcry syslcm 

specification 720 where it is subsequenUy passed to the is initially initiated when the MPS Bean 534 is set for a mode 

database object 236, on to the connection pool 730, and the w d ^ mQURt point recQvery at step 804 M step 8a4> , 

appropnate database, either the transaction database 150 or recoyer method fe md ^ externa i mount po mt ^ 

the query database 152. If the same database is not up and cfaecked ^ fa made at step 806 to evaluate whether or 

the evaluation at step 740 fails, an alternative database must QQt recovery ^ already occurring , If recovery „ already 

be used, but the SQL request is queried at step 744 to occurringj arl exception is thrown at step 808 and exit is 

determine if the SQL command is transferable to the alter- madc at mis ^ ^ |f reCQVcry ^ n0[ alrcady occurrillgi 

nate database. If not, a fatal error occurs at step 746. If the a Us , of moum inls m recovery mode ^ geDerate d in step 

SQL command is transferable, query is made at step 750 to 81Q at stcp 812 a list of mount points which 

see if the alternate database is up and active. Should the m ^ a]so generated Query b made at lhe eva i uat i on 

evaluation fail, subsequent databases may also be queried if st gl8 ^ tQ mc prescnce of avai i ab lc recovery objects in 

the SQL command is transferable. However, as shown in ^ rcco If no ^ objects are avaiUbIe in , he 

FIG. 7, if the second database is unavailable, a fatal error qucuCj thc ^ or othcr databasc ^ scl mto mc « up » modc 

may be generated at 746. Otherwise, the database is up, and fl( g20 ^ for |hat difik fe then unlocked m slep 

the evaluation at step at 750 ^successful and the command m> and ^ recovcry proccs5 fa at stcp g24. If at 

is made available to the database object 236 via the pool evaluaUon stcp 818 recovery objects are io me quC ue, 

specificaUon standard 720 and on to the databases through evahiation is made M t0 whelher or no i the system has gone 

the connection pools 730. past me lock count at step 830 , f ^ queue for the disk 

In order to ensure proper operation of the XDFile data- j n recovery is locked at step 832 for both the lock count 

base object 210, a database status monitor 760 persistently ' evaluation 830 and the queue lock 832 step, control is then 

and on-goingly queries the databases 150, 152. The status is 4J directed to the evaluation step as to whether or not the target 

then returned to a database status object 762. the database fii c cx i sts 334, if mc target file does not exist and thc 

status object may provide information to the recovcry con- evaluation at step 834 fails, the recovery object is removed 

tainer 530 of the XDFile object 210. f rom t nc queue at stcp 840. The status of the recovery is 

The recovery mechanism for the X:Drive system 100 of subsequently put in the request for alert queue at step 842 

the present invention is shown in FIG. 8. The FilelO object 50 and return is then made to thc query stcp 818 to determine 

212 uses a recovery object such as the recovery container whether or not objects are still available for recovery in the 

530 to handle write transactions 406 (as opposed to read queue. 

transactions 404) when the transaction processor 214 fails. If the target file does exist when evaluated at stcp 834, 

The recovery object is transparent to the user, making it evaluation is made as to whether or not the request is more 

easier and more convenient for the user to use the X:Drive 55 current than thc file at step 850. If the request is older than 

system 100 while decreasing the concern that such a user the current file, the recovery object is removed from the 

would have in case of a power outage or other failure in ooe queue at stcp 840, and thc status for the request is put in the 

part of the X:Drive system 100. request or alert queue 842 and control returns back to the 

The FilelO object 212 reports an error to the user, but evaluation step 818 to see if any further recovery objects are 

informs thc user that her request was stored in thc X:Drivc 60 available in the recovery queue. 

system 100 and that the X:Drive system 100 will try to apply If, in evaluating the request, it is found that the request is 

the change as soon as possible. If the storage unit, reprc- more current than thc file, the request is submitted to the 

sented as a mounting point in the EJB cluster becomes XDFile object 210 at step 852. The submission of the request 

unavailable for write transactions 406, the monitoring client to is the XDFile object 210 is not recoverable. If the 

760 updates the EJB network 124 that the status of the 65 submitted request is successful as indicated by the evalua- 

mounting point is "down" Once the mounting point is tion at step 854, the recovery object is removed from the 

available and checked for data integrity, the status is updated queue at step 840, its status is put into the request for alert 
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queue at step 842 and evaluation is made at step 818 as to 
the presence of any additional recovery objects in the 
recovery queue. However, if in submitting the request to the 
XDFUc object 210 at step 852 the submission fails, query is 
made at step 860 as to whether or not the mount point has 5 
gone down. If at step 860 the mount point is still up, the 
request from this mount point is ignored at step 862 and the 
queue for the disk is unlocked at step 864. Control of the 
program is then returned to the recovery object availability 
query in evaluation step 818. 10 

As shown in FIG. 9, the mount point status bean 534 has 
UP, DOWN, and RECOVERY slates. This bean is appli- 
cable to the file database 150, as well as user disks 970, 972 
as well as recovery disks 974, 976. Additionally, the recov- 
ery admin staieful bean 536 is directed towards the recovery 15 
database 980 in order to effect the recovery process 800. 

In order to effect virus scanning and repair features, the 
X:Drive system 100 preferably uses the Java® JN1 (Java 
Native Interface) to access a Norton Anti- Virus or other 
dynamically linked library (NAV.DLL) to scan files for 20 
viruses via a Java® scrvlet. The Java® servlet runs on a 
Windows™ version X server and can use JNI to make calls 
to the NAV.DLL dynamically linked libraries. In effect, the 
Windows™ X machine becomes a specialized NAV.DLL 
server located at the EJB network layer 124 of the XrDrive 25 
system 100, on a sub-network of the resource network. The 
logic integrating the NAV.DLL dynamic linked libraries 
with all X: Drive file writes is shown schematically in the 
flow diagram in FIG. 10. 3Q 

As shown in FIG. 10, the virus scanning sub-system 1000 
takes the file/transaction ID 1002 and a transaction ID 1004 
from a user 1006. The file/transaction ID 1002 is passed to 
a file write process 1008 executed by a SUN® or other web 
server 1010. The file is written to both the database generi- 3J 
cally indicated at reference 1020 and to a temporary file 
storage area 1022. The file write process 1008 passes the file 
transaction ID to the Norton Anti-Virus (NAV) process 
1024. Within the NAV process 1024 is NAV scanner 1026. 
The NAV scanner monitors the data stream or otherwise to 40 
determine and detect the presence of any viruses. If upon 
evaluation the NAV process 1024 detects a virus at evalu- 
ation step 1028, data sink action is taken with respect to the 
database 1020. If no virus is detected, the sequence moves 
to its final termination at step 1030 and data sink action is 45 
taken with respect to a temporary file on medium 1032. 

While both the file and transaction ID 1002 are delivered 
to the file write process 1008, the transaction ID alone 1004 
is transmitted to a fetch location info step 1040 on a SUN® 
or other web server 1010. The fetch location info step 1040 50 
transmits its results to an evaluation step 1042, which 
determines whether or not the file is in the temporary storage 
area 1022. If the file is in the temporary area, the file's 
upload status is shown in step 1044. If the file is not in the 
temporary medium 1022, virus information is fetched at step 55 
1050 in the file status process 1036. 

Once the virus information has been fetched, it is evalu- 
ated as to whether or not there is a virus present at step 1052. 
If there is no virus detected, then the virus evaluation 
terminates and a display of same may be made at step 1054. 60 

However, if evaluation step 1052 indicates the presence of 
one or more viruses, a plurality of virus options may be 
shown and presented to the user at step 1060. Among the 
virus options available are: the cleaning of the virus at step 
1062, moving the virus to a different location at step 1064, 65 
and/or deleting the virus in step 1066. If step 1064 is taken 
with the move of the virus-laden file despite its infectious 
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nature is made, movement of the file with its final destina- 
tion is made in step 1070. 

As shown in FIG. 10, a number of data sink actions are 
taken with respect to information. Additionally, as indicated 
by FIG. 10, the NAV process 1024 is a separate entity and 
may be considered to be a JAVA® servlet/daemon living on 
specialized Windows® NT or other servers. 

In order to make resources available on an on-going basis 
to the virus scanning sub-system 1000 of the present 
invention, a chron file 1074 (a file executing commands on 
a periodic basis according to the time) is used to remove old 
files from a first temporary storage resource 1002. 

FIG. 11 shows the Skip the Download/Save to My Xdrive 
system where a file on the Internet can be transferred over 
to an individual's X:Drive at generally data speeds far faster 
than those available to the end user. This allows the user to 
exercise dominion and control over the file without having 
to bear the burden of downloading it to the local computer 
at the present moment. Once the transfer has taken place 
across the Internet from the host to the X: Drive system 100, 
then the user may download the file stored in his X:Drive 
directory to his local computer at his convenience. 

As X:Drive exists on the Internet network, transferring a 
file from one network resource (such as a web or FTP server) 
to the user's X:Drive is made much faster from the user's 
standpoint by by-passing the local connection to the user and 
allowing the user to submit the transfer request directly to 
the X:Drive network for execution. The X: Drive system 100 
then downloads the requested data from the target server to 
the user's X: Drive over the presumably higher speed con- 
nections of the public Internet. 

As shown in FIG. 11, the Save to My Xdrive system 1100 
first has the user 1110 submit the URL at step 1112. In order 
to access the X:Drive system 100 of the present invention, 
the user submits the URL as well as his or her user name and 
password at step 1114. Upon submitting the URL and (he 
appropriate verification information, evaluation is made of 
the information for authentication purposes at step 1116. If 
the evaluation fails and authentication is not achieved, a 
login form is displayed in conjunction with the previously- 
indicated URL at step 1118. If the request is authenticated, 
it is submitted to the STD/STMX (Skip the Download/Save 
to My Xdrive) queue 1132 at step 1130. A status process is 
then spawned at step 1134. 

Save to My Xdrive status is then checked on an on-going 
basis by using the queue in the temporary storage area at step 
1136. Query is made as to whether or not the transfer is 
complete at step 1140. If the transfer is complete at step 
1140, then the successful completion is indicated to the user 
at step 1142. However, if the transfer is not complete, query 
is made as to the presence of any transfer errors at step 1146. 
If an error has occurred, an error message is displayed to the 
user at step 1148. However, if the transfer is incomplete but 
no errors have occurred, the same is then displayed to the 
user at step 1150, and a short pause is taken at step 1152 for 
re-invoking the check STD process at step 1136. 

Once the STD queue 1132 receives the request, a daemon 
process processes the request from the STD queue at step 
1160. Query is made as to the business logic of the queued 
request at step 1162. If the request fails the business logic 
check 1162, the status is updated at step 1164. Control may 
transfer back to the STD queue 1132. 

If the business logic check succeeds at step 1162, the URL 
site is contacted by the X:Drive system 100 at step 1170 and 
the download process is activated. The data transmitted by 
the URL is then saved in temporary X:Drive space in step 



01/13/2004, EAST Version: 1.4.1 



US 6,351,776 Bl 
19 20 

1172, with the data being transferred then to the user data of the X: Drive system 100 where the server side request 

space at step 1174. The URL site 1180 may exist anywhere processing layer 1210 transmits the data to a query evahi- 

on the Interact so long as it is available to the X:Drive iting whether or not the request is one for metadata at step 

system 100. In a similar manner, a temporary storage space 1212. If the evaluation fails and the request is not one for 
1182 may also exist anywhere on the Internet so long as it s metadata, the network I/O layer 1216 and the resource 

is accessible and controllable by the X:Drive system 100. acccss laycr 12 i8 are invoked in order to provide access to 

Upon transferring data to the user's data space as shown and operation of the transaction database 152. 

m StCP V,l$ f ery - u madC 35 10 thC r -, UC ° e 1 °i ^ lfam i e ? K the request for metadata query at step 1212 succeeds, 
at step 1188. For either success or fajure of the sweessfti * passed on to the resource acccss layer 1218 

file transfer at evaluation step 1188, the status is updated a M and ^ (q ^ ^ L tion k ^ ^ re ^ onse t0 
step 1164 and is passed on to the queue 11« until ^ ^ ^ ^ mctadalabase 150 

is transmitted to the 

either success or an error ^ finally achieved. "The status ^ ^^ation tem 1230 Q f the client 120. The 

process spawned at step 1130 monitors the update status ^ ^ ^ b ^ ^ aUon u n2 Q is 
generated by step 1164 and displays ; the status to the user receiyed b ^ fifc mani latioa 12 30 as weU as its 

during and after the download of the file from the Internet to 1S ^ ^ ^ ^ L b ^ passed Qn to me 

the user's X:Dnve system. u at step m4 to anivB flt a data slnicixlK 1236 

FIG. 12 shows a schematic and flowchart diagram for the lhal ^ lhen ready fof and ^ h passed on to me dala 

client system generally used under Microsoft® Windows™ ^ Uy hycf 1238 for dispUy to , hc ^ who may lhcn 
for achieving the present invention. The X:Dnve system re -i n itiate the process by implementing the file access ser- 
offcrs its clients two basic services: a file access service by 20 v i cc J202 

which files can be uploaded and downloaded to and from . . t inn . t , 

v ^ . .. y a . . , . , ... FIG. 13 shows the X:Dnve system 100 as implemented on 

X:Dnve, as well as a file manipulation service from which „_ . _ M __ .. ... A » n o 

si . a . u u. a a ■ 1 , a n«.v,„f.k»„ a Windows™ X machine, m this case, a Windows 98 
file metadata can be obtained and manipulated. Both of these .. , , t . , ' , ' 

, A _ c . u ■ p 1 machme (an Intel-based personal computer runnmg the 

services rely upon the context of their usage. For example, _fi\v;^™ >oq 

the web client of the present invention uses native upload M Mlcrosoft Wradows 98 W* 0 * s y stcm >- 
and download features as weU as dialogs in the user's web The second frontmost window 1310 of FIG. 13 is headed 
browsers to facilitate the service. b V lhe inscription "My Computer" and shows the presence 

With the use of the web browsers on the local machine, of » at logical letter X: 1312 with the XrDrive logo and 
Windows® X clients use the Windows™ TCP/IP stacks the ^ ww.xdnve^com (X:) This is an example of the 
inherently present with the Windows® version X operating 30 user interface provided by the client application. The 
system. All the file transfers effected by the X:Drive system X:D ™ e s ^ tcm 15 transparent to the user and functions as 
can take place as HTTP POST/GET or, preferably, Web- "V othcr *™ P rcscnt on lhc s y slcm " 
DAV transfers. Generally, two basic layers are present in the If the user were to click on or activate the X:\ dnvc on the 
file manipulation servers of the X:Drive system 100 of the My Computer window 1310, the second window 1320 
present invention. An XML parser operates in conjunction 3s appears (partially obscuring the "My Computer" window 
with an XML data displayer. By coordinating the two basic 1310) and shows the listing under the X:\ Drive . The address 
layers of the file manipulation service, the server is able to of the window 1320 shows the location of the directory as 
respond with generally the same XML code to all clients. being at X:\ 1322. 

The client is then responsible for converting the XML to a Also shown in FIG. 13 is the desktop icon 1330, the start 
relevant data structure and displaying the XML in an appro- *o menu icon 1336, and the system tray icon 1340. These icons 
priale context In the present invention, the JavaScript web accompany the client program 102 and provide greater 
client receives the XML code and parses it into a JavaScript functionality for the user. Each icon serves to activate the 
data structure. A display layer in association with the client client program in accordance with user-settable preferences, 
and/or browser renders the data structure as an HTML FJGrl3 also^ows th« wcW>ased application 1350 in the 
document. The Windows® X client parses the same XML 45 cbackgrtWdrrjehmd":^ 

code, but the display layer renders the data structure into a windowsruThcrweb-basedrapplication window -1350 "is 
device listing that is understood by the Windows® version shown :: in^FIGrl4rNote~should-be"taken-of-the-exact 
X operating system. The importance of this layered archi- coigsnQ fidcncc ^ bctwecn-thc- dircctory structurcs -of webr> 
lecture is that it generally makes trivial the creation of new based:application window-1350 and-the client-based appli- 
cants. Instead of simply creating dynamic web pages (and 50 cation.wmdow 1320:This rorrespondener prnvirfr.^ the n^r . 
thus limiting service to web browsers alone), the X:Drive with a uniform; famifiar. and dei?endable interface upon wim > 
system 100 can enable many platforms, such as operating th e -user-cann ery.- 

systems, without altering the server structure. Most plat- As set forth above, the three accompanying Appendices 
forms come with some sort of XML parsing layers, and &k m aled herein ^ their entiret ^ i5ihe previousIy 
many platforms come with display layers ready made. 55 filcd provisional application. 

Consequently, the time to market may generally be consid- ... . ... ...... 

ered low and efficient establishment and implementation of ^ thc P™« inven ' lon has J*? 0 ^'bed with 
the X:Drive system 100 of the present invention can be n*«d* 10 P^cular embodiments, it is recognized that 
achieved fairly quickly. Additionally, expansion into new additional variations of the present invention may be de V1 sed 
platforms generally becomes much quicker as no alteration 60 w £° ul feparttng from the inventive concept 
of the server structure generally needs to occur as Java® and What is claimed is: 

related program functionalities are highly portable from one l - A client-server system for a network-based data storage 
system to another. and manipulation system, composing: 

In the client system 1200, as shown in FIG. 12, the client a client system, said client system having a file access 
102 has a file access service 1202, including a request 65 service and a file manipulation service; 
processing layer 1204 coupled to a network I/O layer L206. a server, said server providing network-based dala storage 
Commands and data are then transmitted to the server side resources, said server creating and maintaining meta- 
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data regarding stored data, said server responding to 

requests transmitted by said client system, said server 

effecting said requests; 
said server determining if a clieni request is one for 

metadata; 5 
said server providing said metadata if said client request 

is for metadata and transmitting said metadata to said 

file manipulation service; 
said server performing a file action if said client request 1Q 

is not for metadata, said server updating said metadata 

and transmitting said metadata to said file manipulation 

service; 

said file access service having a request processing layer 
for processing requests and a first network I/O layer for 15 
transmitting said requests to said server, 

said file manipulation service having an XML parser, said 
XML parser parsing said metadata from said server, 
said file manipulation service having a data structure, 
said data structure receiving and preserving parsed data 20 
from said parser, and said file manipulation service 
having a data display layer, said data display layer 
operating upon and displaying said parsed data so that 
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metadata may be displayed to inform about data stored 
upon said server; and 

said server having a second network I/O layer, said second 
network I/O layer engaged when said requests are not 
for metadata, said second network I/O layer transmit- 
ting requests for file action, said server having a 
resource access layer, said resource access layer receiv- 
ing transmissions from said second network I/O layer 
and effecting said requests, said resource access layer 
engaged when said requests are for metadata, said 
resource access layer obtaining and transmitting said 
metadata, and said server having a metadata compiler 
in the form of an XML generator, said metadata com- 
piler receiving said metadata from said resource access 
layer, compiling said metadata, and transmitting said 
compiled metadata to said client system; whereby 

said server operates as apparently local to said client 
system and said client system presents operations on 
said server in a manner similar to operations local to 
said client system. 

***** 
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